…eedback

…, docs, GUI

The docuemntation was restructured to seperate out administrator from worksapce administrator in response to security vulnerability on log file traversal.

#7961)

fall back to using the URL of the capabilities document itself.

Update MapMLBaseProxyTest.java to check the cascaded request against the
request URL from the capabilities document OR if that is null, use the
URL OF the capabilities document as the base.

Update assertCascading in MapMLWMTSProxyTest.java to compare against
resource request URL from capabilities document OR if that is null,
use the URL OF the capabilities document as the base.

…ment section

* Centralize the declaration of geotools dependencies to the root pom's
  dependencyManagement and remove `<version>${gt.version}</version>` in
  module poms for consistency.

* Exclude `xml-apis` and apache `fop` in the root pom dependency management section
  Of especial interes for the `gt-app-schema` module not to carry over the
  unnecessary (sice Java 1.6) `xml-apis` jar, whose presence also makes the
  eclipse IDE complain there are multiple sources for classes
  in the `javax.xml.namespace`, `org.w3c.dom`, and other packages.

commit 397981a4e9dc310219270f82b2e560f6d3de4127
Author: Gabriel Roldan <[email protected]>
Date:   Tue Aug 6 12:05:38 2024 -0300

…rom_root_pom

Declare all GeoTools dependencies in the root pom's dependency management section

The way it is stated now is misleading, because the LEGEND_OPTIONS params are required, but they are mentioned after the optional parameters.

…alized standard

see https://discourse.osgeo.org/t/sql-server-plugin-extension/50931/4

Add a data directory under build/cite/ogcapi-features10.

This is an extract of the [release](../../../data/release/) data directory
without the raster layers and their corresponding datasets, for the purpose
of executing the ogcapi-features-1.0 conformance test suite against this
well known datasets.

Note although it adds the shapefiles and geopackage again, they won't incur
in any size overhead for the repository given the way git stores files.

This commit adds support for running CITE (Compliance & Interoperability Testing Evaluation)
tests for `OGC API - Features 1.0`. It includes updates to dependencies, configuration changes,
a new CI workflow, and test data handling to ensure proper validation of GeoServer¿s conformance.

* The new `ogcapi-features10` test suite runs against the latest version of the
  [ogccite/ets-ogcapi-features10:1.7.1-teamengine-5.4.1](https://hub.docker.com/r/ogccite/ets-ogcapi-features10/tags)
   "TEAM Engine and OGC API - Features test suite", using the TeamEngine¿s REST API. Refer to the "Using the REST API"
   section in the [User Guide](https://opengeospatial.github.io/teamengine/users.html) for more details.
* Introduced a new GitHub Actions workflow that builds and runs the CITE tests.
* The CITE tests run against all feature types present in the `release` data directory.
    * Configured the WFS to declare `EPSG:4326` and `EPSG:3857` for all FeatureTypes,
      ensuring that tests do not attempt reprojection between incompatible coordinate systems or boundaries.
    * Disabled the `tiger:giant_polygon` FeatureType as the test suite tries to reproject it
      to CRSs that can't cover its single world-wide polygon.
* Updated the CITE build and run scripts located in `build/cite/` to ensure they can be executed.
    * The existing CITE tests continue to run via CLI commands against the `geoserver-docker.osgeo.org/geoserver-cite:teamengine_latest` image.
      to include only the necessary dependencies for this specific test suite.
    * Updated the `geoserver.war` file used for testing to default to the
      locally built version. A `make war` target has been introduced.
    * Added an `ogcapi-features` Maven profile in `src/web/app/pom.xml`

`EPSG:4087` (WGS 84 / World Equidistant Cylindrical) is a global
projection, while `EPSG:3857` (WGS 84 / Pseudo-Mercator) is not.

Since the `ogcapi-features-1.0` ETS fails while doing coordinate
transformations on itself, despite GeoServer having returned
transformed geometries (albeit outside the area of validity of
the target CRS), let's use two default published CRS's that
cover the whole globe.

Re-enable the `tiger:giant_polygon` layer, since now it can be
reprojected across the declared global CRS's.

…imitations

The ets-ogcapi-features10 test suite will chek the transformed collection items
fall inside the collection's declared spatialExtent (WGS84). In doing so, the test
themselves are limited to 7 decimals for geographic coordinates, and hence will fail
with GeoServer's higher accuracy, despite GeoServer responses being correct.

…nal fixes

Use a patched version of `ogccite/ets-ogcapi-features10:1.8-SNAPSHOT-teamengine-5.4.1`.

Currently, we require the following pull request to be applied:
[Fix global crs codes lookup in discovery collections crs tests](opengeospatial/ets-ogcapi-features10#255)
to the test suite.

This may happen again, hence we're introducing a build step to generate
the required `ogccite/ets-ogcapi-features10` image out of the
`geoserver/ets-ogcapi-features10` fork, using a branch named `geoserver/integration`.

The procedure to maintain that branch is to rebase on top of the upstream
master branch as required, and apply the additional branches with `git merge --no-ff`.

Use a patched ogccite/ets-ogcapi-features10 Docker image with additional fixes

Test ogcapi-features both

* Respects the configured number of decimal places when encoding GeoJSON,
both in the Collection document bounds and for items coordinates (this last
part is performed already by the WFS  GeoJSON encoder)
* The encoded collection bounds fully covers the items, as asserted by
the CITE tests,

… the configured decimal places

…tional to cores

…8036)

The XStream project solved CVE-2024-47072 https://x-stream.github.io/CVE-2024-47072.html

should resolve https://github.com/geoserver/geoserver/security/dependabot/382